FastAPI Dependency Injection: Avanceret DI Container-arkitektur

FastAPI er med sit intuitive design og sine kraftfulde funktioner blevet en favorit til at bygge moderne web-API'er i Python. En af dens kernestyrker ligger i den sømløse integration med dependency injection (DI), som giver udviklere mulighed for at skabe løst koblede, testbare og vedligeholdelsesvenlige applikationer. Selvom FastAPI's indbyggede DI-system er fremragende til simple tilfælde, har mere komplekse projekter ofte gavn af en mere struktureret og avanceret DI container-arkitektur. Denne artikel udforsker forskellige strategier til at bygge en sådan arkitektur og giver praktiske eksempler og indsigter til at designe robuste og skalerbare applikationer.

Forståelse af Dependency Injection (DI) og Inversion of Control (IoC)

Før vi dykker ned i avancerede DI container-arkitekturer, lad os afklare de grundlæggende koncepter:

• Dependency Injection (DI): Et designmønster, hvor afhængigheder leveres til en komponent fra eksterne kilder i stedet for at blive oprettet internt. Dette fremmer løs kobling, hvilket gør komponenter lettere at teste og genbruge.
• Inversion of Control (IoC): Et bredere princip, hvor kontrollen over oprettelse og styring af objekter er omvendt – delegeret til et framework eller en container. DI er en specifik type af IoC.

FastAPI understøtter i sagens natur DI gennem sit afhængighedssystem. Du definerer afhængigheder som 'callable' objekter (funktioner, klasser osv.), og FastAPI løser og injicerer dem automatisk i dine endpoint-funktioner eller andre afhængigheder.

Eksempel (Grundlæggende FastAPI DI):

            
from fastapi import FastAPI, Depends

app = FastAPI()

# Dependency
def get_db():
    db = {"items": []}  # Simulate a database connection
    try:
        yield db
    finally:
        # Close the database connection (if needed)
        pass


# Endpoint with dependency injection
@app.get("/items/")
async def read_items(db: dict = Depends(get_db)):
    return db["items"]

            

              
                Copy
              
            
          

I dette eksempel er get_db en afhængighed, der leverer en databaseforbindelse. FastAPI kalder automatisk get_db og injicerer resultatet (db-ordbogen) i read_items-endpoint-funktionen.

Hvorfor en avanceret DI-container?

FastAPI's indbyggede DI fungerer godt til simple projekter, men efterhånden som applikationer vokser i kompleksitet, tilbyder en mere sofistikeret DI-container flere fordele:

• Centraliseret afhængighedsstyring: En dedikeret container giver en enkelt sandhedskilde for alle afhængigheder, hvilket gør det lettere at styre og forstå applikationens afhængigheder.
• Konfigurations- og livscyklusstyring: Containeren kan håndtere konfigurationen og livscyklussen for afhængigheder, såsom at oprette singletons, styre forbindelser og frigive ressourcer.
• Testbarhed: En avanceret container forenkler test ved at give dig mulighed for nemt at overskrive afhængigheder med mock-objekter eller test-doubles.
• Afkobling: Fremmer større afkobling mellem komponenter, hvilket reducerer afhængigheder og forbedrer kodens vedligeholdelsesvenlighed.
• Udvidelsesmuligheder: En udvidelsesbar container giver dig mulighed for at tilføje brugerdefinerede funktioner og integrationer efter behov.

Strategier til at bygge en avanceret DI-container

Der er flere tilgange til at bygge en avanceret DI-container i FastAPI. Her er nogle almindelige strategier:

1. Brug af et dedikeret DI-bibliotek (f.eks. `injector`, `dependency_injector`)

Der findes flere kraftfulde DI-biblioteker til Python, såsom injector og dependency_injector. Disse biblioteker tilbyder et omfattende sæt funktioner til styring af afhængigheder, herunder:

• Binding: Definere, hvordan afhængigheder bliver løst og injiceret.
• Scopes: Kontrol af livscyklussen for afhængigheder (f.eks. singleton, transient).
• Konfiguration: Styring af konfigurationsindstillinger for afhængigheder.
• AOP (Aspect-Oriented Programming): Opsnapning af metodekald til tværgående anliggender.

Eksempel med `dependency_injector`

dependency_injector er et populært valg til at bygge DI-containere. Lad os illustrere brugen med et eksempel:

            
from dependency_injector import containers, providers
from fastapi import FastAPI, Depends

# Define dependencies
class Database:
    def __init__(self, connection_string: str):
        self.connection_string = connection_string
        # Initialize database connection
        print(f"Connecting to database: {self.connection_string}")

    def get_items(self):
        # Simulate fetching items from the database
        return [{"id": 1, "name": "Item 1"}, {"id": 2, "name": "Item 2"}]


class UserRepository:
    def __init__(self, database: Database):
        self.database = database

    def get_all_users(self):
        # Simulating database request to get all users
        return [{"id": "user1", "name": "Alice"},{"id": "user2", "name": "Bob"}]

class Settings:
    def __init__(self, database_url):
        self.database_url = database_url

# Define container
class Container(containers.DeclarativeContainer):
    config = providers.Configuration()
    settings = providers.Singleton(Settings, database_url = config.database_url)
    database = providers.Singleton(Database, connection_string=config.database_url)
    user_repository = providers.Factory(UserRepository, database=database)

# Create FastAPI app
app = FastAPI()

# Configure container (from an environment variable)
container = Container()
container.config.database_url.from_env("DATABASE_URL", default="sqlite:///:memory:")
container.wire([__name__]) # enables injection of dependencies into FastAPI endpoints

# Dependency for FastAPI
def get_user_repository(user_repository: UserRepository = Depends(container.user_repository.provided)) -> UserRepository:
    return user_repository


# Endpoint using injected dependency
@app.get("/users/")
async def read_users(user_repository: UserRepository = Depends(get_user_repository)):
    return user_repository.get_all_users()

@app.on_event("startup")
async def startup_event():
    # Container initialization
    container.init_resources()

            

              
                Copy
              
            
          

Forklaring:

• Vi definerer vores afhængigheder (Database, UserRepository, Settings) som almindelige Python-klasser.
• Vi opretter en Container-klasse, der arver fra containers.DeclarativeContainer. Denne klasse definerer afhængighederne og deres providers (f.eks. providers.Singleton for singletons, providers.Factory for at oprette nye instanser hver gang).
• Linjen container.wire([__name__]) muliggør dependency injection i FastAPI-endpoints.
• Funktionen get_user_repository er en FastAPI-afhængighed, der bruger container.user_repository.provided til at hente UserRepository-instansen fra containeren.
• Endpoint-funktionen read_users injicerer UserRepository-afhængigheden.
• config giver dig mulighed for at eksternalisere afhængighedskonfigurationerne. De kan så komme fra miljøvariabler, konfigurationsfiler osv.
• startup_event bruges til at initialisere de ressourcer, der administreres i containeren.

2. Implementering af en brugerdefineret DI-container

For mere kontrol over DI-processen kan du implementere en brugerdefineret DI-container. Denne tilgang kræver mere arbejde, men giver dig mulighed for at skræddersy containeren til dine specifikke behov.

Eksempel på en grundlæggende brugerdefineret DI-container:

            
from typing import Callable, Dict, Type, Any
from fastapi import FastAPI, Depends

class Container:
    def __init__(self):
        self.dependencies: Dict[Type[Any], Callable[..., Any]] = {}
        self.instances: Dict[Type[Any], Any] = {}

    def register(self, dependency_type: Type[Any], provider: Callable[..., Any]):
        self.dependencies[dependency_type] = provider

    def resolve(self, dependency_type: Type[Any]) -> Any:
        if dependency_type in self.instances:
            return self.instances[dependency_type]

        if dependency_type not in self.dependencies:
            raise Exception(f"Dependency {dependency_type} not registered.")

        provider = self.dependencies[dependency_type]
        instance = provider()
        return instance

    def singleton(self, dependency_type: Type[Any], provider: Callable[..., Any]):
        self.register(dependency_type, provider)
        self.instances[dependency_type] = provider()


# Example Dependencies
class PaymentGateway:
    def process_payment(self, amount: float) -> bool:
        print(f"Processing payment of ${amount}")
        return True # Simulate successful payment


class NotificationService:
    def send_notification(self, message: str):
        print(f"Sending notification: {message}")


# Example Usage
container = Container()
container.singleton(PaymentGateway, PaymentGateway)
container.singleton(NotificationService, NotificationService)

app = FastAPI()

# FastAPI Dependency
def get_payment_gateway(payment_gateway: PaymentGateway = Depends(lambda: container.resolve(PaymentGateway))):
    return payment_gateway


def get_notification_service(notification_service: NotificationService = Depends(lambda: container.resolve(NotificationService))):
    return notification_service


@app.post("/purchase/")
async def purchase_item(payment_gateway: PaymentGateway = Depends(get_payment_gateway), notification_service: NotificationService = Depends(get_notification_service)):
    if payment_gateway.process_payment(100.0):
        notification_service.send_notification("Purchase successful!")
        return {"message": "Purchase successful"}
    else:
        return {"message": "Purchase failed"}

            

              
                Copy
              
            
          

Forklaring:

• Klassen Container administrerer en ordbog over afhængigheder og deres providers.
• Metoden register registrerer en afhængighed med dens provider.
• Metoden resolve løser en afhængighed ved at kalde dens provider.
• Metoden singleton registrerer en afhængighed og opretter en enkelt instans af den.
• FastAPI-afhængigheder oprettes ved hjælp af en lambda-funktion til at løse afhængigheder fra containeren.

3. Brug af FastAPI's `Depends` med en Factory-funktion

I stedet for en fuldt udbygget DI-container kan du bruge FastAPI's Depends sammen med factory-funktioner for at opnå en vis grad af afhængighedsstyring. Denne tilgang er enklere end at implementere en brugerdefineret container, men giver stadig nogle fordele i forhold til direkte at instantiere afhængigheder inde i endpoint-funktioner.

            
from fastapi import FastAPI, Depends
from typing import Callable

# Define Dependencies
class EmailService:
    def __init__(self, smtp_server: str):
        self.smtp_server = smtp_server

    def send_email(self, recipient: str, subject: str, body: str):
        print(f"Sending email to {recipient} via {self.smtp_server}: {subject} - {body}")


# Factory function for EmailService
def create_email_service(smtp_server: str) -> EmailService:
    return EmailService(smtp_server=smtp_server)


# FastAPI
app = FastAPI()

# FastAPI Dependency, leveraging factory function and Depends
def get_email_service(email_service: EmailService = Depends(lambda: create_email_service(smtp_server="smtp.example.com"))):
    return email_service


@app.post("/send-email/")
async def send_email(recipient: str, subject: str, body: str, email_service: EmailService = Depends(get_email_service)):
    email_service.send_email(recipient=recipient, subject=subject, body=body)
    return {"message": "Email sent!"}

            

              
                Copy
              
            
          

Forklaring:

• Vi definerer en factory-funktion (create_email_service), der opretter instanser af EmailService-afhængigheden.
• Afhængigheden get_email_service bruger Depends og en lambda til at kalde factory-funktionen og levere en instans af EmailService.
• Endpoint-funktionen send_email injicerer EmailService-afhængigheden.

Avancerede overvejelser

1. Scopes og livscyklusser

DI-containere tilbyder ofte funktioner til at styre livscyklussen for afhængigheder. Almindelige scopes inkluderer:

• Singleton: En enkelt instans af afhængigheden oprettes og genbruges i hele applikationens levetid. Dette er velegnet til afhængigheder, der er stateless eller har globalt scope.
• Transient: En ny instans af afhængigheden oprettes, hver gang den anmodes. Dette er velegnet til afhængigheder, der er stateful eller skal isoleres fra hinanden.
• Request: En enkelt instans af afhængigheden oprettes for hver indgående anmodning. Dette er velegnet til afhængigheder, der skal opretholde tilstand inden for rammerne af en enkelt anmodning.

Biblioteket dependency_injector har indbygget understøttelse for scopes. For brugerdefinerede containere skal du selv implementere logikken for scope-styring.

2. Konfiguration

Afhængigheder kræver ofte konfigurationsindstillinger, såsom databaseforbindelsesstrenge, API-nøgler og feature flags. DI-containere kan hjælpe med at administrere disse indstillinger ved at tilbyde en centraliseret måde at tilgå og injicere konfigurationsværdier.

I dependency_injector-eksemplet tillader config-provideren konfiguration fra miljøvariabler. For brugerdefinerede containere kan du indlæse konfiguration fra filer eller miljøvariabler og gemme dem i containeren.

3. Test

En af de primære fordele ved DI er forbedret testbarhed. Med en DI-container kan du nemt erstatte reelle afhængigheder med mock-objekter eller test-doubles under test.

Eksempel (Test med `dependency_injector`):

            
import pytest
from unittest.mock import MagicMock
from dependency_injector import containers, providers
from fastapi import FastAPI, Depends
from fastapi.testclient import TestClient

# Define dependencies (same as before)
class Database:
    def __init__(self, connection_string: str):
        self.connection_string = connection_string

    def get_items(self):
        return [{"id": 1, "name": "Item 1"}, {"id": 2, "name": "Item 2"}]


class UserRepository:
    def __init__(self, database: Database):
        self.database = database

    def get_all_users(self):
        return [{"id": "user1", "name": "Alice"},{"id": "user2", "name": "Bob"}]

class Settings:
    def __init__(self, database_url):
        self.database_url = database_url

# Define container (same as before)
class Container(containers.DeclarativeContainer):
    config = providers.Configuration()
    settings = providers.Singleton(Settings, database_url = config.database_url)
    database = providers.Singleton(Database, connection_string=config.database_url)
    user_repository = providers.Factory(UserRepository, database=database)

# Create FastAPI app (same as before)
app = FastAPI()

# Configure container (from an environment variable)
container = Container()
container.config.database_url.from_env("DATABASE_URL", default="sqlite:///:memory:")
container.wire([__name__]) # enables injection of dependencies into FastAPI endpoints

# Dependency for FastAPI
def get_user_repository(user_repository: UserRepository = Depends(container.user_repository.provided)) -> UserRepository:
    return user_repository


# Endpoint using injected dependency (same as before)
@app.get("/users/")
async def read_users(user_repository: UserRepository = Depends(get_user_repository)):
    return user_repository.get_all_users()

@app.on_event("startup")
async def startup_event():
    # Container initialization
    container.init_resources()

# Test
@pytest.fixture
def test_client():
    # Override the database dependency with a mock
    database_mock = MagicMock(spec=Database)
    database_mock.get_items.return_value = [{"id": 3, "name": "Test Item"}]

    user_repository_mock = MagicMock(spec = UserRepository)
    user_repository_mock.get_all_users.return_value = [{"id": "test_user", "name": "Test User"}]

    # Override container with mock dependencies
    container.user_repository.override(providers.Factory(lambda: user_repository_mock))

    with TestClient(app) as client:
        yield client
    container.user_repository.reset()


def test_read_users(test_client: TestClient):
    response = test_client.get("/users/")
    assert response.status_code == 200
    assert response.json() ==  [{"id": "test_user", "name": "Test User"}]

            

              
                Copy
              
            
          

Forklaring:

• Vi opretter et mock-objekt for Database-afhængigheden ved hjælp af MagicMock.
• Vi overskriver database-provideren i containeren med mock-objektet ved hjælp af container.database.override().
• Testfunktionen test_read_items bruger nu den mockede database-afhængighed.
• Efter testens udførelse nulstiller den containerens overskrevne afhængighed.

4. Asynkrone afhængigheder

FastAPI er bygget oven på asynkron programmering (async/await). Når du arbejder med asynkrone afhængigheder (f.eks. asynkrone databaseforbindelser), skal du sikre dig, at din DI-container og dine afhængigheds-providers understøtter asynkrone operationer.

Eksempel (Asynkron afhængighed med `dependency_injector`):

            
import asyncio
from dependency_injector import containers, providers
from fastapi import FastAPI, Depends

# Define asynchronous dependency
class AsyncDatabase:
    def __init__(self, connection_string: str):
        self.connection_string = connection_string

    async def connect(self):
        print(f"Connecting to database: {self.connection_string}")
        await asyncio.sleep(0.1) # Simulate connection time

    async def fetch_data(self):
        await asyncio.sleep(0.1) # Simulate database query
        return [{"id": 1, "name": "Async Item 1"}]

# Define container
class Container(containers.DeclarativeContainer):
    config = providers.Configuration()
    database = providers.Singleton(AsyncDatabase, connection_string=config.database_url)

# Create FastAPI app
app = FastAPI()

# Configure container
container = Container()
container.config.database_url.from_env("DATABASE_URL", default="sqlite:///:memory:")
container.wire([__name__])

# Dependency for FastAPI
async def get_async_database(database: AsyncDatabase = Depends(container.database.provided)) -> AsyncDatabase:
    await database.connect()
    return database


# Endpoint using injected dependency
@app.get("/async-items/")
async def read_async_items(database: AsyncDatabase = Depends(get_async_database)):
    data = await database.fetch_data()
    return data


@app.on_event("startup")
async def startup_event():
    # Container initialization
    container.init_resources()

            

              
                Copy
              
            
          

Forklaring:

• Klassen AsyncDatabase definerer asynkrone metoder ved hjælp af async og await.
• Afhængigheden get_async_database er også defineret som en asynkron funktion.
• Endpoint-funktionen read_async_items er markeret som async og afventer resultatet af database.fetch_data().

Valg af den rigtige tilgang

Den bedste tilgang til at bygge en avanceret DI-container afhænger af din applikations kompleksitet og dine specifikke krav:

• For små til mellemstore projekter: FastAPI's indbyggede DI eller en factory-funktionstilgang med Depends kan være tilstrækkelig.
• For større, mere komplekse projekter: Et dedikeret DI-bibliotek som dependency_injector tilbyder et omfattende sæt funktioner til styring af afhængigheder.
• For projekter, der kræver finkornet kontrol over DI-processen: Implementering af en brugerdefineret DI-container kan være den bedste løsning.

Konklusion

Dependency injection er en kraftfuld teknik til at bygge skalerbare, vedligeholdelsesvenlige og testbare applikationer. Selvom FastAPI's indbyggede DI-system er fremragende til simple tilfælde, kan en avanceret DI container-arkitektur give betydelige fordele for mere komplekse projekter. Ved at vælge den rigtige tilgang og udnytte funktionerne i DI-biblioteker eller implementere en brugerdefineret container, kan du skabe et robust og fleksibelt afhængighedsstyringssystem, der forbedrer den overordnede kvalitet og vedligeholdelsesvenlighed af dine FastAPI-applikationer.

Globale overvejelser

Når man designer DI-containere til globale applikationer, er det vigtigt at overveje følgende:

• Lokalisering: Afhængigheder relateret til lokalisering (f.eks. sprogindstillinger, datoformater) bør styres af DI-containeren for at sikre konsistens på tværs af forskellige regioner.
• Tidszoner: Afhængigheder, der håndterer tidszonekonverteringer, bør injiceres for at undgå hårdkodning af tidszoneinformation.
• Valuta: Afhængigheder til valutakonvertering og -formatering bør styres af containeren for at understøtte forskellige valutaer.
• Regionale indstillinger: Andre regionale indstillinger, såsom talformater og adresseformater, bør også styres af DI-containeren.
• Multi-tenancy: For multi-tenant-applikationer bør DI-containeren kunne levere forskellige afhængigheder til forskellige tenants. Dette kan opnås ved hjælp af scopes eller brugerdefineret logik til afhængighedsløsning.
• Overholdelse og sikkerhed: Sørg for, at din strategi for afhængighedsstyring overholder relevante databeskyttelsesregler (f.eks. GDPR, CCPA) og sikkerhedsbest practices i forskellige regioner. Håndter følsomme legitimationsoplysninger og konfigurationer sikkert inden for containeren.

Ved at tage højde for disse globale faktorer kan du skabe DI-containere, der er velegnede til at bygge applikationer, der opererer i et globalt miljø.